To fix this issue, you should explicitly declare the permissions key in the workflow. The preferred method is to set it at the top level (after name: but before on:), so it applies to all jobs and reinforces repository security. The minimal permission almost always required by a workflow that only checks out code and uploads/downloads artifacts is contents: read. The best way to address this is to add:

permissions:
  contents: read

on line 2, pushing the rest of the lines down. No additional methods, imports, or definitions are required for this change since it's a pure YAML configuration edit.

To fix the problem, you should explicitly set the least required permissions for the job to avoid accidentally exposing write privileges to the GITHUB_TOKEN. Since the workflow only clones the repository, fetches commits, and checks out code (all reading operations), it should only need read access to repository contents. Thus, you should add a permissions block at the job (DCI-lint) level granting contents: read. This ensures the job does not have unnecessary write privileges. The change is to insert the following under jobs: DCI-lint: (after line 9, before runs-on): permissions: contents: read.

To fix the problem, add a permissions block to limit the GITHUB_TOKEN's permissions—minimally to read-only unless write privileges are needed. This can be set at the top level of the workflow (affecting all jobs) or per job. Based on the given workflow, no step appears to require modifying repository or pull request content directly; the jobs use dependency installation, caching, and run scripts, but do not interact with GitHub APIs in a way that requires write access. Therefore, the minimal and recommended change is to add, at the top of .github/workflows/integration-tests.yml, immediately after name: Integration Tests, a permissions: block set to contents: read. This approach is explicit and disables unnecessary write permissions.

The best way to fix this problem is to explicitly define the permissions: block in the workflow, limiting the permissions granted to the GITHUB_TOKEN as tightly as possible. Since this workflow only needs to read repository content (for code checkout, paths filtering, and possibly caching), we can safely set permissions: contents: read at the root level. This ensures all jobs inherit this restrictive permission unless they individually override it. The top of the workflow file (beneath the name: line) is the appropriate place to insert the permissions: block.

The best way to fix the issue is to add an explicit permissions block to the workflow, either at the top (workflow) level or (if jobs have specific requirements) per job. Adding it at the top level ensures all jobs inherit these settings (unless overridden in the individual job), ensuring the principle of least privilege throughout. Since most CI workflows only require read access to the repository content, set contents: read as a minimal starting point. If specific jobs require more, those jobs can override individually.

File/region to change: .github/workflows/main.yml, directly after the name: (line 1).
Required: Insert the minimal block:

permissions:
  contents: read

No new methods, imports, or definitions are needed.

To fix the problem, explicitly define a permissions block at the top (root) of .github/workflows/pr.yml to restrict the default permissions granted to GITHUB_TOKEN. The recommended minimum is to set all permissions to read unless you know the jobs require write for specific scopes (which they almost never do for jobs triggered by PRs). Since the workflow only delegates to other workflows, and unless otherwise required, set permissions: read-all, which grants read-only access to all scopes.

Add the following block after the name: and before on:. No changes to existing jobs are required, nor are new imports or definitions needed for this fix.

The best way to fix this issue is to explicitly set the least privileged permissions block at the root level of your workflow file, so that all jobs inherit these permissions unless they override them. In this case, since the workflow primarily coordinates and invokes other composite workflows (via uses), and unless they require broader privileges, the most secure minimal permissions would usually be contents: read. This limits the default GitHub token to minimal access, preventing write or administrative actions. To implement: insert the following block after the name line, before on::

permissions:
  contents: read

If you know that any of the called workflows require additional permissions beyond reading contents, you can extend the block as appropriate; otherwise, start with the most conservative setting.

How to do it:

• Edit .github/workflows/pr.yml
• After the name: ... line, add a new line with the permissions: block as shown.

There are no package dependencies to add; it is purely a YAML edit.

To fix the problem, you should add a permissions block at the workflow root level in .github/workflows/pr.yml. This will apply least-privilege permissions to all jobs unless overridden by individual jobs or their referenced included workflows. The minimal recommended permissions block is:

permissions:
  contents: read

If your jobs or the included workflows require additional permissions (for example, to create/update pull requests, issues, or more), you may expand the block as needed, but start with least privilege (usually just contents: read for typical CI jobs).

The change must be made at the top level of .github/workflows/pr.yml (just below name: and above on:). No additional imports or code definitions are needed. This change does not affect existing functionality and simply restricts the default permissions inherited by GitHub Actions jobs.

To fix the problem, explicitly declare the permissions for the relevant job(s) or at the workflow root in .github/workflows/unit-tests.yml, restricting the GitHub token permissions according to the principle of least privilege. For this workflow, basic read access for source code (contents: read) suffices for tasks like checking out code, running tests, and uploading artifacts. If additional write permissions are ever needed (such as uploading comments to pull requests), those can be granted specifically; however, for the provided workflow, contents: read fully suffices.

Specifically, add:

• At the workflow root (top-level):

  permissions:
    contents: read

  This grants only read access to the repo contents for all jobs in the workflow, and is the minimal starting point recommended by CodeQL.

Edit lines at the top of .github/workflows/unit-tests.yml to insert this block just below name: and above on:.